[US-14.3 / OBT-248] Role tag on user cards: Member/Manager/Admin - #34
[US-14.3 / OBT-248] Role tag on user cards: Member/Manager/Admin#34levigtri wants to merge 2 commits into
Conversation
Every user card on the Users page now displays exactly one role badge
with a distinct color, instead of only platform admins having a tag.
- Add UserRole type and optional role field to UserListResponse,
matching the derived role exposed by the backend (US-14.2); the
field is optional so older API responses still work
- Add manager and member Badge variants with Shema tokens
- UserCard renders the role badge via a role -> {variant, icon, label}
map with precedence platform_admin > manager > member, falling back
to is_platform_admin when the API does not send role
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
Warning Review limit reached
Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: QUIET Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
1 participant
[US-14.3 / OBT-248] Role tag on user cards: Member/Manager/Admin
Summary
Every user card on the Users page now shows exactly one role tag — Member, Manager, or Admin — each with a distinct color and icon. Previously only platform admins had a tag (the telha Shield badge), so members and managers were visually indistinguishable. The role comes from the new
rolefield exposed by the backend inUserListResponse(US-14.2:platform_adminifis_platform_admin, elsemanagerif the user manages at least one project, elsemember), with a client-side fallback for older API responses that do not send the field.Changes
UserRoletype and optionalrolefield —src/types/user.tsAdds
export type UserRole = "member" | "manager" | "platform_admin"and the optional fieldrole?: UserRoletoUserListResponse. The field is optional on purpose so the frontend tolerates API versions that predate US-14.2.Barrel re-export —
src/types/index.tsRe-exports
UserRoleby name from./userso it can be imported from@/typeslike the other user types.managerandmemberbadge variants —src/components/ui/badge.tsxAdds two Badge variants after
admin:manager(bg-azul/25 text-verde border border-azul/60) andmember(bg-areia/30 text-verde border border-areia), both using Shema design tokens so each role has a distinct color.Always-present role tag —
src/components/pages/UsersPage/UserCard.tsxReplaces the
user.is_platform_admin && <Badge variant="admin">conditional with a single role badge rendered for every card, driven by arole -> { variant, icon, label }map:platform_adminkeeps the current visual (admin variant + Shield),manageruses the manager variant + UserCog,memberuses the member variant + User icon. Role resolution isuser.role ?? (user.is_platform_admin ? "platform_admin" : "member"), preserving precedence platform_admin > manager > member. The Active/Inactive badge stays alongside it, and lucide'sUsericon is imported asUserIconto avoid colliding with theUsertype.Type of Change
Testing
npm run typecheck— passes with no errors.npm run lint— 0 errors (only the pre-existingreact-hooks/exhaustive-depswarning inProjectsPage.tsx).npm run build— production build succeeds.rolepresent the API value wins; without it, platform admins keep the Admin tag and everyone else shows Member, matching the pre-US-14.2 behavior plus the new always-visible tag.